Attacking The Supply Chain: Developer

In 2021, we published an entry identifying the weak parts of the supply chain security. In the face of the surge in documented attacks, the entry gave a summarized overview of how malicious actors found gaps to abuse and take advantage of for possible gains and disruptions.

In this entry, we focus on one specific part of the supply chain: the developers themselves. To find a suitable attack model focusing on the developer, we must first understand who is considered the developer (and therefore the target), their workflow, and their daily tools. We also set the focus on how developers and their respective tools can be abused to compromise the supply chain, and how understanding these threat scenarios allows developers and the organizations to decide which tradeoffs to make to protect their projects and themselves.

Who is “The Developer”?

We can use a dictionary definition, stating a developer is a person that develops computer software. In our understanding, a person who writes code. This includes popular programming or scripting languages like Java, JavaScript, TypeScript, Go, Python, C/C++, and many other languages, including infrastructure or container deployment definitions such as Dockerfiles, Kubernetes, Terraform HCLs, and many others. From that description alone, the definition covers various parts of the IT industry, including every person writing code and security researchers, among many others.

Although the workflow itself may vary from developer to developer and from company to company, it will most likely fall into one of the following categories depending on how the developer is using the integrated developer environments (IDE):

• Local IDE: The developer has the IDE installed in his own machine locally. In this case, the developer can
  • Pull or push code to the remote repository, and execute the build and debug it locally, or
  • Commits changes to the remote repository, triggering the continuous integration/continuous delivery (CI/CD) event, and lead to the quality assurance (QA) assessment or even a deployment into the production environment.
• Cloud IDE: The developer uses cloud services-hosted IDE, such as AWS Cloud9, Visual Studio Online, GitHub Codespaces, and many other platforms available today. In this case, the developer machine works just as a gateway, usually via browser to the IDE, and the main code executions are performed in the cloud IDE’s remote hosts inside the cloud service provider.

As the developer definition covers multiple professions, some workflows could exclude some items from the list. For example, research purpose proof of concept would more likely not set up a whole CI/CD pipeline. However, most workflows will include usage of an IDE for the development. In this entry, we focus on local IDEs, as we also discussed specific platforms in our previous entries on the security risks of online coding platforms.

A Use Case of a Local IDE

When using the local IDE, one of the use cases is when the developer pulls the code to their local computer. This code is further compiled into binary format for it to be executed. There is an implicit trust in the code written by previous contributors because most developers assume that the codebase is likely not “dirty” since it works as intended. This trust is not only carried to and in the source code itself, but also in the build scripts, libraries, dependencies, and other project files when included. That brings us to the first threat scenario: injecting malicious actions into the project files or build scripts.

As developers, do we read the build scripts after pulling remote code prior to their execution?

We tested various popular IDEs and programming languages by injecting malicious build commands to the build scripts or project files if and when applicable. These are the results of version of IDEs we tested:

• Eclipse 2022-09
• Apache NetBeans 16
• PyCharm 2022.2.4
• IntelliJ IDEA 2022.03
• Visual Studio 2022
• Visual Studio Code 1.73.1

When we consider the generic threat model, we also must include every non-controlled input. This includes the source code, its files, and including its pre- and post-build scripts and IDE extensions, if applicable. We previously wrote about the danger of possible malicious IDE extensions in one of our 2020 articles.